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The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above Is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent tenn adjustment. See 37 CFR 1.704(b). 

Status 

1 )K Responsive to communication(s) filed on 17 February 2004 . 
2a)KI This action is FINAL. 2b)n This action is non-final. 

3) n Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) |EI Claim(s) 22.24-27.29-32 and 34-53 is/are pending in the application. 

4a) Of the above claim(s) 

5) n Claim(s) is/are allowed. 



is/are withdrawn from consideration. 



6) KI Claim(s) 22.24-27.29-32.34-38 A1 -47 and 50-53 is/are rejected, 

7) M Claim(s) 39.40.48 and 49 is/are objected to. 

8) n Claim(s) are subject to restriction and/or election requirement. 



Application Papers 

9)n The specification is objected to by the Examiner 
1 0)0 The drawing(s) filed on 



is/are: a)n accepted or b)n objected to by the Examiner. 



Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing{s) is objected to. See 37 CFR 1.121(d). 
1 1 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-1 52. 

Priority under 35 U.S.C. § 119 

12)D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)n All b)n Some * c)^ None of: 

1 .□ Certified copies of the priority documents have been received. 
2.n Certified copies of the priority documents have been received in Application No. . 



3.n Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 
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DETAILED ACTION 



IDS 



The Information Disclosure filed 2/17/04 (paper # 13) was 
not considered because a copy of the reference cited was not 
provided . 



Applicant's arguments filed 2/17/04 have been fully 
considered but they are not persuasive. 

Applicant argued that the Examiner did not provide specific 
citing to Varma teaching of the "local application sharing 
logic" and "remote application sharing logic". Claim 22 is a 
system claim. Varma teaching is more or less a method. Hence, 
mapping of the claimed structures to the teaching of Varma can 
only be done by inference to the functions disclosed in Varma. 
Varma provides for collaboration, sharing of application 
(workspace) among clients. A client can send/receive 
modifications to the workspace to/from a collaboration server. 
Hence the collaboration software routine for sending the 
modifications from the client to the server would be the 'local 
application sharing logic' as claimed. The collaboration 
software routine in the server for receiving the modifications 
would be the 'remote application sharing logic' as claimed. 



Response to Arguments 
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Applicant argued that Varma teaches a queue, and that a 
'queue' is not the same as a 'buffer' . Applicant cited 
definition from webepedia in support of this assertion. The 
argument is not persuasive because the terms 'queue' and 
'buffer' are often used interchangeably in the art. It is well 
known in the art that a 'queue' is a type of 'buffer', 
specifically a queue is a FIFO buffer. (See generally patent 
4473880, 4763243, 5123089 - short excerpts from the patents are 
attached herein). Furthermore, Applicant's disclosure on the 
usage of the buffer would seem to indicate that its functions as 
FIFO - i.e. as a queue rather as a general temporary storage 
area. (See page 32 lines 12-22) . Furthermore, any data 
structure that temporary hold data for later retrieval would 
read on 'buffer' as claimed. Since Varma' s queue can temporary 
hold the modification 'events' data and permit the data to be 
retrieved later (in FIFO order) , it is a buffer as claimed. 

Applicant argued that Smith and Varma are not combinable. 
The argument is not persuasive because Smith and Varma are both 
dealing with the problem of exchanging messages in network; hence 
they are analogous art. Smith is used to show that is well known 
in the communication art to ask a receiver if it is ready to 
receive and to transmit when the receiver is ready. 
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Claim Rejections - 35 USC § 103 



The following is a quotation of 35 U.S.C. § 103(a) which 
forms the basis for all obviousness rejections set forth in this 
Office action: 

(a) A patent may not be obtained though the invention is 
not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject 
matter pertains. Patentability shall not be negatived by 
the manner in which the invention was made. 

Claims 22, 27, 32, 37, and 46 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Varma US patent 
6,33 6,134 and further in view of Smith et al. US patent 
6,282,564. 

As set forth in claim 22, Varma discloses a system for 
ensuring synchronization of multiple applications at remote 
locations (through the collaboration and partition servers 31 and 
32), the system comprising: local application sharing logic 
configured to receive events to be shared from a plurality of 
local applications; see col, 5, lines 39-63 (the applications that 
will be shared are located on the clients) , the logic application 
sharing logic further configured to transmit the events (the 
applications will send the modifications to the partition or 
collaboration servers; see col. 7, lines 22-31, col. 8, line 4- 
col. 10, line 36); remote application sharing logic configured to 
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receive the events from the local application sharing logic (the 
remote application sharing logic will receive the modifications 
that were made at the local client) , the remote application 
sharing logic further configured to transmit the events to a 
plurality of remote applications, (after collaborating the 
modification with the other modifications the updated workspace 
modification will be sent to the remaining clients) ; and remote 
event buffering logic configured to buffer the events received by 
the remote application sharing logic (the FIFO buffer found in the 
partition server will be an aspect of the buffer) the remote even 
buffering logic further configured to determine if the remote 
applications are ready to receive the events (the buffer and the 
respective servers will determine when a modification is needed, 
through this determination it is determined when the remote 
applications are ready to receive events) . 

Varma expressed the desired to make sure the remote 
applications received all transmitted events (col. 7-10 lines 5- 
10) . However, Varma does not specifically disclose sending an 
inquiry to the remote applications requesting notification when 
the remote applications are ready to receive the events, and 
transmit the events to the remote applications when the remote 
applications indicate a ready-to-receive status. The processes of 
inquiry a remote receiver for ready- status prior to transmission 
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is well known in the data communication art. Smith discloses 
method for communicating information with step to inquiry whether 
the receiving device is ready and to begin transmission when the 
receiving device returns an acknowledgement indicating the 
receiving device is ready [col. 2 lines 6-16, col. 19 lines 43-52]. 
It would have been obvious for one of ordinary skill in the art to 
inquiry ready status of the remote applications because it would 
have improved the reliability of the system by ensuring that a 
remote application would not miss an event because it was not 
ready to receive. 

As set forth in claims 27, Varma discloses a method for 
ensuring synchronization of multiple applications at remote 
locations, the method comprising: transmitting events to be shared 
from a plurality of local applications (through the collaboration 
and partition servers, 31 and 32) ; receiving events in a local 
application sharing logic; transmitting the events from the local 
application sharing logic; receiving events, transmitted from the 
local application sharing logic, in a remote application sharing 
logic see col. 5, lines 39-63 (the applications that will be shared 
are located on the clients) ; determining if a plurality of remote 
applications are ready to receive the events (after collaborating 
the modification with the other modifications the updated 
workspace modification will be sent to the remaining clients) ; and 
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transmitting the events from the remote application sharing logic 
to the remote applications when the remote applications are ready 
to receive the events (the buffer and the respective seirvers will 
determine when a modification is needed, through this 
determination it is determined when the remote applications are 
ready to receive events) . 

Varma expressed the desired to make sure the remote 
applications received all transmitted events (col. 7- 10 lines 5- 
10) . However, Varma does not specifically disclose sending an 
inquiry to the remote applications requesting notification when 
the remote applications are ready to receive the events, and 
transmit the events to the remote applications when the remote 
applications indicate a ready-to-receive status. The processes of 
inquiry a remote receiver for ready- status prior to transmission 
is well known in the data communication art. Smith discloses 
method for communicating information with step to inquiry whether 
the receiving device is ready and to begin transmission when the 
receiving device returns an acknowledgement indicating the 
receiving device is ready [col. 2 lines 6-16, col. 19 lines 43-52]. 
It would have been obvious for one of ordinary skill in the art to 
inquiry ready status of the remote applications because it would 
have improved the reliability of the system by ensuring that a 
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remote application would not miss an event because it was not 
ready to receive. 

As set forth in claims 32, Varma discloses a system for 
ensuring synchronization of multiple application at remote 
locations, said system comprising: means for transmitting events 
to be shared from a plurality of local applications (through the 
collaboration and partition servers, 31 and 32) ; means for 
receiving events in a local application sharing logic; means for 
transmitting the events from the local application sharing logic; 
means for receiving events, transmitted from the local application 
sharing logic, in a remote application sharing logic; see col. 5, 
lines 3 9-63 (the applications that will be shared are located on 
the clients) ; means for buffering the events received in the 
remote application sharing logic; means for determining if a 
plurality of remote applications are ready to receive the events 
(after collaborating the modification with the other modifications 
the updated workspace modification will be sent to the remaining 
clients) ; and means for transmitting the events from the remote 
application sharing logic to the remote applications when the 
remote applications are ready to receive the events (the buffer 
and the respective servers will determine when a modification is 
needed, through this determination it is determined when the 
remote applications are ready to receive events) . 
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Varma expressed the desired to make sure the remote 
applications received all transmitted events (col. 7-10 lines 5- 
10) . However, Varma does not specifically disclose sending an 
inquiry to the remote applications requesting notification when 
the remote applications are ready to receive the events, and 
transmit the events to the remote applications when the remote 
applications indicate a ready-to-receive status. The processes of 
inquiry a remote receiver for ready- status prior to transmission 
is well known in the data communication art. Smith discloses 
method for communicating information with step to inquiry whether 
the receiving device is ready and to begin transmission when the 
receiving device returns an acknowledgement indicating the 
receiving device is ready [col. 2 lines 6-16, col. 19 lines 43-52]. 
It would have been obvious for one of ordinary skill in the art to 
inquiry ready status of the remote applications because it would 
have improved the reliability of the system by ensuring that a 
remote application would not miss an event because it was not 
ready to receive. 

As per claims 37 and 46, Varma as modified by Smith is 
inherently pacing the rate at which events are shared. Since 
events are not send to the remote application unit it indicates 
that it is ready to receive, the rate at which events are shared 
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to the remote application is effectively 'paced' to the readiness 
of the remote application. Hence, Varma system as modified has 
pacing a rate at which events are shared as claimed. 

Claims 24-26, 29-31, 34-36, 38 and 47 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Varma and Smith and 
further in view of Hales et al. US patent 5,938,723. 

Varma discloses a synchronization of clients for enabling the 
clients to collaborate in workspaces. Varma additionally discloses 
the usage of a buffer. However, Varma does not disclose having the 
buffer send information indicating the buffer is full, to suppress 
input or to indicate the readiness to receive input. As set forth 
in claims 24, 29, and 34, Hales discloses a system further 
comprising: means for suspending the transmission of the events 
from the local applications when the remote application sharing 
logic indicates that the means for buffering exceeds a threshold; 
see col. 13, line 60-col. 14, line 4. As set forth in claims 25, 
30, and 35 Hales discloses a system wherein the means for 
suspending the transmission further comprises: means for 
suppressing input to the local applications when the remote 
application sharing logic indicates that the means for buffering 
exceeds the threshold; see col. 13, lines 60-col. 14, line 4. As 
set forth in claims 26, 31, and 36, 1-tale discloses a system 
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wherein the means for suspending the transmission further 
comprises: means for enabling input to the local applications when 
said remote application sharing logic indicates that the means for 
buffering is ready to receive the events; see col. 13, line 60- 
col. 14, line 4. It would have been obvious to a person of 
ordinary skill in the art at the time this invention was made to 
have provided the buffer of Varma, with the means for indicating 
that the buffer is full, to suppress input or to indicate 
readiness to receive input, as taught by Hales. The rationale is 
as follows: It would have been desirable to have had the means for 
providing the system with status information related to the 
buffer. As Hales teaches the desirability of having means for 
indicating the buffer is full, to suppress input or to indicate 
readiness to receive input, one of ordinary skill would have been 
motivated by Hales teaching to have provided the buffer of Varma 
with the means for indicating that the buffer is full, to suppress 
input or to indicate readiness to receive input, thereby having 
provided system status information for the buffer to permit smooth 
synchronization of the system through the operation of the buffer. 

As per claim 38 and 47, since Varma system as modified by 
Hales suspends transmission of the events when the buffer is 
full (i.e. buffer count exceeded a threshold), Varma system as 
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modified effectively paced the transmission of the event based 
on the buffering count exceeding a threshold as claimed. 

Claims 41-45 and 50-53 are rejected under 35 U.S.C. 103 (a) as 
being unpatentable over Varma and Smith and further in view of 
Mima et al. US patent 5,654,726. 

As per claims 41 and 50, Varma does not disclose sending a 
message to a user inputting events about the status of another 
sharing participant in processing the events. In similar field 
of invention, Mima teaches providing feedback to the user 
inputting events about the status of another sharing participant 
(Visually indicating on the sender screen the sender pointer 
position as seen by the remote receiver taking into account 
delay time between the participants. See col. 2 line 20-27, col. 4 
line 50-59) . It would have been obvious for one of ordinary 
skill in the art to combine the teaching of Mima with Varma 
because it would have improved the system by reducing 
participant mental burden and enabling smooth transmission of 
information (Mima col . 2 lines 20-27). 

As per claims 42 and 51, Mima teaches presenting a pacing 
meter indicator to the user (the relative distance of the sender 
actual pointer position to confirmed position and the predicted 
pointer location - see fig. 7). 
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As per claim 43, Mima does not teach using color to 
indicate delay amount. The delay amount would be reflected in 
the relative distance between the sender actual pointer position 
and the confirmed pointer position from the remote receiver. 
The usage of color would have been a matter of design choice. 
It would have been obvious for one of ordinary skill in the art 
to use colors to indicate delay amount because it would have 
presented a visual cue correspond to the magnitude of the delay. 

As per claims 44-45 and 52-53, Mima teaches calculating the 
delay magnitude (see col . 5 lines 32-47) by calculating a delta 
time between when a throttle event (the sending of the pointer 
position) was sent and a time that a reply was received (when 
the ACK packet is received) . 

Allowable Subject Matter 

Claims 39-40 and 48-49 are objected to as being dependent 
upon rejected base claims, but would be allowable if rewritten 
in independent form including all of the limitations of the base 
claim and any intervening claims. 
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Other prior art made of record 



The prior art made of record and not relied upon is 

considered pertinent to applicant's disclosure. 

Ohmori et al . , "Cooperative Control for Sharing 
Applications Based on Distributed Multiparty Destop Conference 
System: MERMAID," Communications, 1992. ICC 92, Conference 
record, SUPERCOMM/ICC '92, IEEE International Conference on, 14- 
18 June 1992, Pages : 1069-1075 vol.2. 

The article discloses an X-window system for collaboration 

by sharing existing application via an events dispatcher located 

on each workstation for forwarding events to other workstations. 

Mukherjee et al . US patent 6,058,416. 

The patent teaches a method for sharing and maintaining 
consistency in a collaborative system distributing events among 
shared applications. 



THIS ACTION IS MADE FINAL. Applicant is reminded of the 
extension of time policy as set forth in 37 CFR 1.136(a) . 

A shortened statutory period for reply to this final action 
is set to expire THREE MONTHS from the mailing date of this 
action. In the event a first reply is filed within TWO MONTHS 
of the mailing date of this final action and the advisory action 



Conclusion 
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is not mailed until after the end of the THREE-MONTH shortened 
statutory period, then the shortened statutory period will 
expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated 
from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier 
communications from the examiner should be directed to Dung Dinh 
whose telephone number is (703) 305-9655. The examiner can 
normally be reached on Monday- Thursday from 7:00 AM - 4:30 PM. 
The examiner can also be reached on alternate Friday. 

If attempts to reach the examiner by telephone are 
unsuccessful, the examiner's supervisor, Glenton Burgess can be 
reached at (703) 305-4792. 

Any inquiry of a general nature or relating to the status of 
this application should be directed to the Group receptionist 
whose telephone number is (703) 305-3900. 

Any response to this final action should be mailed tos 
Box AF 

Commissioner of Patents and Trademarks 
Washington, DC 2 0231 
or fcDced to: 

(703) 872-9306 

Hand-delivered responses should be brought to Crystal Park II, 
2121 Crystal Drive, Arlington. VA, Fourth Floor (Receptionist) . 




Dung Dinh 
Primary Examiner 
April 29, 2004 



Enclosure : 

Excerpts from patents 5123089, 4753243, and 4473880 





us -PAT-NO: 



5123089 



DOCUMENT- IDENTIFIER : 



US 5123089 A 



TITLE: 



Apparatus and protocol for local area network 



KWIC 



Detailed Description Text - DETX (58) : 

When a sending network node controller attempts to log-on to a receiving 
network node controller, its ID is either stored as the current sender or, if 
there is already a sender, its ID is put into a queue of ID'S within the 
receiving network node controller waiting to log-on to it. T he . .queue with in 
the receiving network node controller is a FIFO buffer , with the new ID'S being 
put at the end of the queue . 

Current US Original Classification - CCOR (1) : 



709/237 



04/28/2004, EAST Version: 1.4.1 





US-PAT-NO: 



4763243 



DOCUMENT -IDENTIFIER: 



US 4763243 A 



TITLE: 



Resilient bus system 



KWIC 



Detailed Description Text - DETX (49) : 

Now, central subystem 14, as the receiving unit, (slave) performs the 
sequence of operations of FIG. 4b. Briefly, the integrity circuits of block 
14-10 perform a check of each part of the information received from system bus 
2. As seen from FIG. 3b, in the absence of bus parity OK signal BSPAOKOlO 
being forced to a binary ONE, the response circuits of block 14-12 are 
inhibited from generating a response. As previously discussed, this causes the 
timeout circuits of block 20 to generate a negative acknowledgement signal. As 
seen from FIG. 4b, this causes memory subsystem 16 to retry the same transfer 
of information during a subsequent cycle of operation. If the retry is 
successful, the central subsystem response circuits of block 14-12 are 
operative to generate an acknowledgement signal indicating acceptance which 
completes the memory operation. The acknowledgement signal causes the request 
to be stored in an input register (e.g. FIFO, buffer, queue). 



Current US Original Classification - CCOR (1) : 



710/107 



04/28/2004, EAST Version: 1.4.1 





US-PAT-NO: 



4473880 



DOCUMENT -IDENTIFIER: 



US 4473880 A 



TITLE: 



Arbitration means for controlling access to a bus shared 
by a number of modules 



KWIC 



Detailed Description Text - DETX (43) : 

The grant queu e (412) is a thr ee-deep FIFO which is used to buffej : granted 
requests waiting for bus time.' — CTniike the tlme^ordered queue, the glrant queue 
has only one request at the head of the queue in one of the modules at any one 
time. The request at the head of the grant queue is guaranteed to be the next 
request to go out onto the bus. After the request has been made, then it is 
popped off of the grant queue. The purpose of the grant queue is to allow the 
arbiter to proceed independently of and in parallel with the bus access 
protocol and to get as much as three grants ahead of the bus. As long as the 
arbiter can generate grants as fast or faster than the bus can use them, all of 
the internal delays due to both time ordering and binary arbitration will not 
introduce delays or dead cycles onto the bus. While the bus is busy with a 
particular request, the arbiter is able to work in parallel on generating a 
grant for a request to be put on the bus at a future time. The bus rarely 
needs to wait for a grant. The bus for handling data, address and control 
information forms no part of the present invention and therefore is not 
described herein. Any of many well known buses and bus protocols may be 
employed, one such bus is described in the above -referenced copending 
application Ser. No. 336,866, of David Budde et al . 



Current US Original Classification - CCOR (1) : 



710/112 



04/28/2004, EAST Version: 1.4.1 



